Threat Model for SPARK Frauds

As we add rewards for SP retrieval checks performed by SPARK, we must design a robust fraud detection mechanism to combat malicious nodes. In this document, we describe the threat model - what are the adversaries and possible attack vectors.

IMPORTANT

We assume SPARK will check retrievals using the recently introduced HTTP transport only. Checking Bitswap and Graphsync retrievals are out of the scope.

A job (a retrieval check) is defined as a pair (cid, address). The client is expected to retrieve cid from address using the HTTP protocol.

See for a detailed description of job scheduling and retrieval workflow.

Adversaries

• A malicious Storage Provider that wants to inflate its reputation artificially.

• A malicious SPARK client that wants to be rewarded for work they did not do.

• A malicious SPARK client operated by an SP that flags other SPs as unreliable, thus harming their reputation.

• A Storage Provider that runs its own fleet of SPARK clients that are colluding together to game the system and improve the reputation of the SP.

Attack vectors

• An SP can easily get a /24 block of 256 unique IP addresses. They can spin 256 SPARK instances and run a modified client that checks only jobs retrieving from this SP and reporting all other jobs as failed (cannot reach the SP). They are still earning SPARK rewards and boosting their own reputation.
  • CryptoEconLab is best positioned to solve this.
  • We should bring this up in our sync meeting with senior leadership.

Client-side

1. The client does not perform the retrieval check and reports a fake successful retrieval.

2. The client does not perform the retrieval check and reports the retrieval as not successful.
   • Pretend that the server cannot be reached or did not respond.
   • Pretend that the server returned the wrong payload (content verification failed).

3. The client performs the retrieval but reports different results than observed in order to harm the reputation of competing SPs.
   1. Skew metrics like TTFB, TTLB and download speed (bandwidth).
   2. Pretend that the server cannot be reached or did not respond.
   3. Pretend that the server returned the wrong payload (content verification failed).

4. The client starts the retrieval check, waits for the response headers and discards the response body (CAR stream with content) in order to save bandwidth.

5. The client does not verify the integrity of the received content (whether the blocks in the CAR stream build up to the requested CID).

6. The client retrieves the given CID but from a different SP.

7. The client dials the given provider but retrieves a different CID.

8. The client retrieves the given CID from the given provider but uses a different protocol than HTTP - bitswap or graphsync.

9. The client performs a retrieval check that was not scheduled by the SPARK Orchestrator (or the decentralised algorithm we want to implement in the future).

10. The client performs the given retrieval check at the wrong time. E.g. minutes or hours later than scheduled.
    • Q: Is this actually a problem?

11. If using retrieval attestations:
    1. The client re-uses an attestation from a previous job in order to submit false data for the current retrieval check. E.g. to save bandwidth by not making any new retrieval request, just reporting the same result as in the previous job.
    2. The client uses an attestation given to a different client, e.g. to report the job as completed without making the retrieval check.

12. The client retrieves the given CID from the given SP but requests only a subset of data (e.g. the root block). See IPFS Path Gateway Specification and Trustless Gateway Specification for more details.
    1. Set request header Accepts: application/vnd.ipld.raw to request a single, verifiable raw block to be returned.
    2. Add query string param ?format=raw to request a single raw block.
    3. Use the request header Range to request a subset of content.
    4. Append /{path} to the URL to retrieve only one file instead of the entire bundle

13. The client crafts the request in such a way that an honest SP returns back an error despite the fact that it would be able to serve the requested content. The client’s goal is to harm SP’s reputation.
    1. Set the request header If-None-Match to an etag value obtained by other means, hoping that the server returns 304 Not Modified with an empty response body.
    2. Set only-if-cached via request headers or query string, hoping to receive 412 Precondition Failed
    3. Set Accepts header or ?format query string to an invalid value.

SP side

I could not find any attack vectors that SP can perform on its own without help from a colluding SPARK client. However, the are ways how SPs can break our scheme.

1. SP does not send back any attestation token.

2. SP sends back an invalid attestation token, one that does not match the request.

3. SP does not keep an unsealed copy of the data. It can sign the retrieval but not serve the data. Or maybe they retrieve content via Saturn.

Collusion

1. A colluding client bypasses the SP Retrieval API and accesses the raw data where it’s stored by Boost/Lotus in order to compute any proofs required by our system, e.g. proof of retrieval(PoR) or proof of data possession (PDP).

2. A colluding client has access to SP’s private key and creates any signatures required by our system without communicating with the SP Retrieval API at all.

3. The SP does not send the requested CAR stream and responds with an empty response body. A colluding client does not flag this problem and reports a successful retrieval.

4. The SP send an incorrect payload (content verification fails). A colluding client does not flag this problem and reports a successful retrieval.

5. The SP does not provide any attestation for retrieval requests made by non-colluding SPARK clients. This way, we cannot trust the data reported by non-colluding clients (we can’t tell if the reported result is legitimate). The only trusted data we have for this SP is coming from colluding SPARK clients, which are able to manipulate the metrics.